Сообщений 26 
Оценка 91
[+4/-1]
Оценить 
| Сообщений 26 Оценка 91
[+4/-1]
Оценить
|
| Идиома RAII Управляемые и неуправляемые ресурсы Паттерн Dispose Прагматичный взгляд на паттерн Dispose Упрощенная версия паттерна Dispose Заключение |  |
“Не стоит следовать некоторой идиоме только потому, что так делают все или так где-то написано” Мысли автора статьи во время чтения и рефакторинга чужого кода |
Ни для кого не будет секретом, что платформа .NET поддерживает автоматическое управление памятью. Это значит, что если вы создадите объект с помощью ключевого слова new, то вам не нужно будет самостоятельно заботиться о его освобождении. Сборщик мусора определит «достижимость» объекта, и если на объект не осталось корневых ссылок, то он будет освобожден. Однако, как только речь заходит о ресурсах, таких как сокет, буфер неуправляемой памяти, дескриптор операционной системы и т.д., то сборщик мусора, по большому счету, умывает руки и весь головняк по работе с такими ресурсами ложится на плечи разработчика.
А как же финализаторы? – спросите вы. Ну, да, есть такое дело, финализаторы действительно предназначены для освобождения ресурсов, но проблема в том, что время их вызова не детерминировано, а это значит, что никто не знает, когда они будут вызваны и будут ли вызваны вообще. Да и порядок вызова финализаторов не определен, поэтому при вызове финализатора некоторые «части» вашего объекта уже могут быть «разрушены», поскольку их финализаторы уже были вызваны. В общем, финализаторы – они-то есть, но это скорее «страховочный трос», а не нормальное средство управления ресурсами.
В языке С++, в котором нет никаких встроенных средств для автоматического управления памятью помимо умных указателей, уже давно активно применяется паттерн (или идиома) для своевременного освобождения ресурсов (*). Эта идиома носит название «Захват ресурса есть инициализация» (RAII - Resource Acquisition Is Initialization) и заключается в следующем. Ресурс захватывается в конструкторе и освобождается в деструкторе, а поскольку деструкторы вызываются автоматически, то и дополнительных усилий по управлению ресурсами больше не требуется.
| ПРИМЕЧАНИЕ В С++, в отличие от C#, память тоже является ресурсом. Поэтому идиома RAII в языке С++ применяется как для освобождения динамически выделенной памяти, так и для освобождения любых других ресурсов, типа дескрипторов ОС или сокетов. |
Не удивительно, что эта же идея детерминированного управления ресурсами перекачивала и в другие более «умные» и «управляемые» среды, такие как .NET или Java (**) в виде интерфейса IDisposable (в языке C#) и метода dispose (в Java).
|
В Java 7 наконец-то появилась конструкция, аналогичная конструкции using языка C#: try-with-resource statement. |
Но, поскольку эти среды более умные, по сравнению со старичком С++, и основные проблемы, связанные с управлением памятью, в них решены, то переехала эта идиома не слишком хорошо. Нет, поймите меня правильно, переехала она вполне успешно, но для этого вам нужно использовать блок using (для языка C#) или try-with-resources statement (в Java 7). Если же вы «забудете» ими воспользоваться, то от вашего детерминированного освобождения ресурсов не останется и следа.
// Открываем файл внутри блока using
using (FileStream file = File.OpenRead("foo.txt"))
{
// Выходим из функции при выполнении некоторого условияif (someCondition) return;
// Файл будет закрыт автоматически при выходе из блока using
}
// А что, если кто-то откроет файла вне блока using?
FileStream file2 = File.OpenRead("foo.txt"); |
Однако это не единственная сложность, которая возникает при работе с ресурсами в .NET. Как мы вскоре увидим, использование обычного метода для освобождения ресурсов обладает и некоторыми другими проблемами. Поскольку метод Dispose освобождает ресурсы, то вызов финализатора уже не нужен, и его нужно отменить, кроме того, метод Dispose разрушает инвариант класса, что дает пользователю возможность получить разрушенный или частично разрушенный объект. А это требует дополнительных проверок как в методе Dispose, так и во всех публичных методах класса.
Все это привело к тому, что относительно простая идиома RAII вылилась на платформе .NET в паттерн, который так и называется “паттерн Dispose”. Однако прежде чем переходить к его рассмотрению, давайте рассмотрим два типа ресурсов, существующие на платформе .NET: управляемые и неуправляемые ресурсы.
В .NET существует два типа ресурсов: управляемые и неуправляемые. Причем отличить их довольно просто: к неуправляемым ресурсам относятся только «сырые» ресурсы, типа IntPtr, сырые дескрипторы сокетов или что-то в этом духе; если же с помощью идиомы RAII этот ресурс упаковали в объект, захватывающий его в конструкторе и освобождающий в методе Dispose, то такой ресурс уже является управляемым. По сути, управляемые ресурсы – это «умные оболочки» для неуправляемых ресурсов, для освобождения которых не нужно вызывать какие-то хитроумные функции, а достаточно вызвать метод Dispose интерфейса IDisposable.
class NativeResourceWrapper : IDisposable
{
// IntPtr – неуправляемый ресурсprivate IntPtr nativeResourceHandle;
public NativeResourceWrapper()
{
// «Захватываем» неуправляемый ресурс путем вызова специальной функции
nativeResourceHandle = AcquireNativeResource();
}
publicvoid Dispose()
{
// Освобождаем захваченный ресурс, опять же, путем вызова какой-то специальной// функции
ReleaseNativeResource(nativeResourceHandle);
}
// Есть еще и финализатор, но его роль будет раскрыта позднее
~NativeResourceWrapper() {...}
} |
Таким образом, любой объект может владеть ресурсами двух типов: он может непосредственно содержать неуправляемый ресурс (например, IntPtr) или же он может содержать ссылку на управляемый ресурс (например, NativeResourceWrapper), при этом в обоих случаях объект, содержащий один из этих ресурсов, сам становится управляемым ресурсом. Это может показаться не слишком принципиальным, но понимать разницу между двумя типами ресурсов очень важно, поскольку работать с ними приходится по-разному.
Итак, мы знаем, что объект может владеть двумя типами ресурсов: управляемыми и неуправляемыми; а также то, что у нас есть два способа освобождения ресурсов: детерминированный, с помощью метода Dispose и недетерминированный, с помощью финализатора (***). А теперь давайте посмотрим, как со всем этим добром жить и, главное, как это добро освобождать.
| ПРИМЕЧАНИЕ К сожалению в языке C# для финализаторов выбран тот же самый синтаксис (тильда, за которой идет имя класса), который используется для деструкторов в языке С++. Но семантика деструктора и финализатора очень разная, поскольку деструктор подразумевает детерминированное освобождение ресурсов, а финализатор – нет. |
Идея паттерна Dispose состоит в следующем: давайте мы всю логику освобождения ресурсов поместим в отдельный метод, и будем вызывать его и из метода Dispose, и из финализатора, при этом, давайте добавим флажок, который бы говорил нам о том, кто вызвал этот метод. Поскольку эта простая идея содержит довольно большое количество подробностей, то давайте изложим паттерн Dispose по пунктам.
class Boo : IDisposable {} |
// Для не-sealed классов
protected
virtual
void Dispose(bool disposing) {}
// Для sealed классовprivatevoid Dispose(bool disposing) {} |
public
void Dispose()
{
Dispose(true/*called by user directly*/);
GC.SuppressFinalize(this);
} |
Метод GC.SuppressFinalize(), во-первых, должен вызываться после вызова Dispose(true), а не перед ним, поскольку если метод Dispose(true) «упадет» с исключением, то выполнение финализатора не отменится. Во-вторых, GC.SuppressFinalize() должен вызываться даже для классов, не содержащих финализаторы, поскольку финализатор может появиться у его наследника (т.е. мы должны вызывать метод GC.SuppressFinalize() во всех не-sealed классах).
void Dispose(bool disposing)
{
if (disposing)
{
// Освобождаем только управляемые ресурсы
}
// Освобождаем неуправляемые ресурсы
} |
~Boo()
{
Dispose(false/*not called by user directly*/);
} |
Не забывайте, что финализатор может быть вызван даже для частично сконструированных объектов, если конструктор этого класса сгенерирует исключение. Так что код очистки неуправляемых ресурсов должен учитывать то, что ресурсы еще не захвачены (****).
|
Здесь я, например, не говорил о том, как можно получить «утечку ресурсов» при появлении исключений или о проблемах с изменяемыми значимыми типами, реализующими интерфейс IDisposable. Об этом я уже писал ранее в заметках «Гарантии безопасности исключений» и «О вреде изменяемых значимых типов» соответственно. |
void Dispose(bool disposing)
{
if (disposed)
return; // Ресурсы уже освобождены// Освобождаем ресурсы
disposed = true;
}
publicvoid SomeMethod()
{
if (disposed)
thrownew ObjectDisposedException();
} |
// А вы уверены, что оно вам нужно?
class Foo : CriticalFinalizerObject { } |
Если вам показалось, что работа с ресурсами в .NET неоправдано сложна, то у меня по этому поводу есть две новости: одна хорошая, а другая – не очень. Новость «не очень» заключается в том, что работа с ресурсами даже сложнее, чем здесь описано (*****), хорошая же заключается в том, что в большинстве случаев вся эта сложность нас с вами касаться практически не будет.
Вся сложности реализации паттерна Dispose связаны с предположением о том, что один и тот же класс (или иерархия классов) может одновременно содержать как управляемые, так и неуправляемые ресурсы. Но давайте подумаем, а зачем вообще нам может понадобиться хранить неуправляемые ресурсы напрямую в классах бизнес-логики? А как же пресловутые Принципы Единой Ответственности (SRP – Single Responsibility Principle) и Здравого Смысла? Идиома RAII, описанная ранее, успешно используется десятки лет и предназначена как раз для таких случаев: если у вас есть неуправляемый ресурс, то вместо того, чтобы работать с ним напрямую, оберните его в управляемую оболочку и работайте уже с нею.
Если посмотреть на .NET Framework, то можно заметить, что там используется именно такой подход: для всех ресурсов создается оболочка, которая прячет внутри всю сложность по работе с ресурсами, предоставляя пользователю лишь вызвать метод Dispose для явной очистки ресурсов (ну, и финализатор, на всякий случай). Кроме того, для большей части неуправляемых ресурсов операционной системы такие оболочки уже сделаны, и изобретать велосипед не нужно.
Все это я веду к тому, что не нужно смешивать в коде бизнес-логику и логику по работе с неуправляемыми ресурсами. И то, и другое достаточно сложно само по себе и заслуживает отдельного класса. Вот и получается, что данный паттерн «оптимизирован» на очень редкий случай (что класс может содержать и управляемые, и неуправляемые ресурсы), при этом наиболее распространенный случай, когда класс содержит только управляемые ресурсы, становится очень неудобным в реализации и сопровождении.
Если мы с вами знаем, что ни один человек не собирается смешивать управляемые и неуправляемые ресурсы в одном месте, так почему бы не реализовать это в коде явным образом? Мы можем оставить метод Dispose и, вместо дополнительного метода Dispose с совсем невнятным булевым параметром, добавить виртуальный метод DisposeManagedResources, имя которого будет четко говорить о том, что мы должны освободить именно управляемые ресурсы. Модификатор доступа этого метода должен быть аналогичным нашему методу Dispose(bool), т.е. protected virtual для не-sealed классов или private для sealed классов.
class SomethingWithManagedResources : IDisposable
{
publicvoid Dispose()
{
// Никаких Dispose(true) и никаких вызовов GC.SuppressFinalize()
DisposeManagedResources();
}
// Никаких параметров, этот метод должен освобождать только неуправляемые ресурсыprotectedvirtualvoid DisposeManagedResources() {}
} |
С первого взгляда такой подход может показаться слишком уж прагматичным, однако посудите сами: в книге Framework Design Guidelines описанию Dispose паттерна посвящено два десятка страниц, при этом ее авторы рекомендуют добавлять финализаторы только в случае острой необходимости. При этом все мы знаем, что смешивать два типа ресурсов в одном классе плохо, но все же следуем паттерну, который это поощряет, а не запрещает.
При разработке библиотечных классов или бизнес-классов, которые будут использоваться в десятке других проектов, то следовать всем описанным выше принципам вполне разумно. К повторно используемому коду предъявляются другие требования и при их проектировании нужно следовать другим принципам: простота в использовании и расширяемость таких классов значительно важнее стоимости сопровождения.
Если же вы проектируете классы бизнес-логики или простые библиотеки с ограниченным кругом пользователей, то можно не морочить себе голову с «канонами», а использовать упрощенную версию этого паттерна, которая работает только с управляемыми ресурсами.
| Сообщений 26 Оценка 91
[+4/-1]
Оценить
|